《恰如其分的软件架构》读后小结（二）

架构与开发过程

重新审视一下敲代码这个活计。本质上是把现实中的概念和需求，转化成CPU可以理解的计算机语言的过程。整个过程中真正在敲代码的部分，恐怕在所有工作中的占比是有限的。因为你总得去开需求评审会，总得去设计划分系统组件，总得去联合调试接口，总得去修复一些bug。那么架构是什么呢，它在开发中的哪个阶段，又有什么作用呢。

软件架构，就是系统设计，以及它对诸如性能，安全和可修改性等系统质量产生的影响。

架构是系统的骨架，直接影响质量属性，并约束整个系统。

计算系统的软件架构是解释该系统所需的结构体的集合，其中包括：软件元素，元素之间的相互关系，以及二者各自的属性——SEI

以上三种说法摘自本书，软件工程这门课程本身也就诞生了几十年，所以“架构”这个词在概念上并没有像什么公理、定理一样有统一的定义。可以包含描述软件系统的各个层级的关系抽象，也可以包含软件开发过程中的所有约束。

软件系统的设计由开发者的决策和意图构成，设计可以被划分为软件架构和详细设计。

二者的界限比较模糊，架构不仅仅是系统的宏观层面。影响到系统质量属性的细节，也属于架构范畴。

按照本书的说法——也许也是软件开发正规军的玩法——一个软件系统的诞生，是把现实世界的知识和需要，抽象成“领域知识”，转化成软件概念；经过架构设计，再进行各个层级的设计细化，描述好各种软件概念之间的关系，最终实现各部分编码的过程。使用书中的术语就是——从领域模型，细化到设计模型，最后到代码模型的过程，或者说，是把现实中的概念和需求不断抽象和建模，通过架构设计、分治、功能场景描述等手段，最后细化到代码实现的过程。其实从提出需求到敲代码，无论是在脑子里，还是在图纸上，还是在各种绘图软件里，总会有个思考和设计的过程，不同之处在于软件的规模有多大、团队的规模有多大。

如书中所说，从软件架构到详细设计，很难找到两者之间的边界在哪里。具体书中给的建议之中，倒是看到了诸如敏捷开发、瀑布流这些熟悉的字眼，对开发模式的理解有了内在原因上的概念补充。

架构与团队协作

如果软件规模谈得上要有架构了，那么很可能就不是一个人两个人能搞定的事了。那么架构师在团队中应该是个什么角色呢，架构师画画架构图-工程师写写接口-程序员去补充实现？ —— 当然没有这么层级分明和简单明了。

教授团队成员架构思想是必要的，统一思想更容易实现开发目标

最为理想的是要求开发者能够拥有架构意识

类似于要有编程规范，当然编程规范也可以作为架构约束的一部分。团队成员需要统一架构认知，架构师或高级工程师有必要在团队中推广架构约束。书中举出了新人加入团队带来的风险和针对解决方案：

风险实例：新人加入团队，带来架构侵蚀和架构偏移的风险：

团队沟通上，

使用模块模型-层次结构图来介绍系统

结构图中会包含一些领域术语，可以建立知识库作为参考学习资料

描述系统中的质量属性与设计原则

通过组件与连接器职责列表，系统运行时的关系图来描述运行时的系统状态

团队扩张时，在迭代开发中对代码结构的冲击是很难避免的。我们说新人磨合也好，说培训制度也罢，无论是老人带新人，还是开会、培训、代码review，从代码层次来讲，其实就是向新人灌输当前代码的业务内容和架构约束。而我们与书中不同之处在于，我们没有从领域模型到设计模型的各种文档，或许对号入座之后能找到部分文档，比如产品给出的需求文档、模型图，设计师给出的设计稿，可以算作领域模型的一部分；核心算法流程图、系统分层框图、核心模块类图、核心流程时序图，都可以算作设计模型的一部分。但相对而言还是脱节的，无法复原整个设计过程的原貌，当然成本是一个关键问题。

或许有一个问题是很值得思考的，你如何理解现在维护的系统的架构，假如团队有新成员加入，有什么方法可以快速让新成员理解这个系统。

知识整合

最后一个值得一提的点就是对现有知识体系的整合。虽然现有的开发知识体系都是基于Android/Java/编程相关的，但是对号入座之下，还是在架构这个可大可小的概念里得到了一些新的认知。比如原来积累的类图、时序图等在架构设计中处于哪一环，除了原本认识到除了辅助设计还有什么其他作用；比如编程规范其实可以算作架构风格约束的一部分；比如老带新、分享与培训，很多我们自然而然在做的事，本质上就是维护架构约束不被破坏与侵蚀等等。

印象比较深刻的是书中对模式的解读，可谓是入木三分了。

有时一组约束总是出现的很有规律，在这种情况下对这一组约束进行命名，并作为一个模式，是很有意义的，这些模式架构风格，元素关系的类型，以及使用他们的约束共同组成的规范。架构风格限制了设计从而使开发人员可以控制风险，并获得某种质量属性。

模式是一种为解决重复发生的问题，而提炼出来的可复用的解决方案。模式可以应用在低级概念上，而且可以包含很多细节，比如编程语言中的惯用语法。也可以应用在中极概念上，比如表达设计中常见的对象和类模式的设计模式，还可以用更高级的概念上。

对于设计模式——单例、工厂、观察者、适配器、责任链等等，基于面向对象语言的设计模式——Java从业者可以说是每天都在打交道了。而书中的描述是简练而抽象的，我们是管中窥豹，略见一斑，作者则是从基础规律上切入描述的，大家不在一个层级上。但是在印证之下，对模式概念的理解会更通透一些。